在前一篇有提到，XML是用來「儲存」和「傳輸」資料的一種「結構化」「資料格式」。這裡就先介紹一些我曾經接觸過的資料交換格式。
第一種是很單純的資料型式，幾乎沒有什麼格式可言，也有人稱此為CSV(Common-Separated Values)，如下圖所示。
其好處是建置簡單，缺點是必須要額外的文件或口頭補充說明，才能知道其中各欄位的意義。

第二種格式比CSV多了一點資料以外的格式，如下圖所示。
可以大概「猜到」H10,H20表示的是表頭(Header)，而D10表示的是表身(Detail)。每列後面的欄位，有人喜歡用固定長度去切，有人喜歡用分隔符號(eg.|)，我還碰過有人兩者並用的。
這個的建置比CSV略難一些，缺點也類似。

在談第三種格式之前，要先提到資料交換「標準」的觀念，兩家公司要進行資料交換，只要兩家公司談好一種格式就好了，但如果在一對多或多對多的情境下，建置很多種格式會變成很大的負擔。於是就有一群專家，跳出來制定所謂的「資料交換標準」格式，以減輕各家公司的負擔。就像幾個不同國家的人在一起，用英語溝通，每個國家的人只要在英語一種語言和母語之間轉換即可，不必學習多國語言。

以下這是聯合國制定的UN/EDIFACT EDI標準格式(註：範例資料不是100%正確，我只是提供大概的樣子做為參考)。如下圖所示，第一次看到的人會驚呼：這什麼鬼呀！但冷靜下來之後，可以發現每列都有相同的規律，就是最前面都有固定三個字元的英文字母。沒錯，那就是Tag最早期的概念，在EDI稱為Segment，用以識別該列所代表的意義，例如：NAD(Name and Address)、DTM(Date and Time)。
這種資料格式的結構化程度更高了，但是大概要專家才能建置這種資料格式。

UN/EDIFACT在歐洲和亞洲比較普遍使用，美國人就不屑使用，自己弄了一套美國標準，稱之為ANSI X12，格式大概如下圖所示。
敏銳一點的邦友可以發現，ANSI X12和UN/EDIFACT有類似的做法，即在每一列最前面使用Tag來識別該列所代表的意義，只是ANSI X12的Tag有三個字元和兩個字元的差別。
也許你會問，為什麼不使用聯合國UN/EDIFACT一種格式就好了？唉，當年為了要接
IBM/HP/COMPAQ從美國來的電子訂單，誰敢不建置ANSI X12呀？

最後一種就是此次文章的主題，XML格式，如下圖所示。
可以看出來跟前面幾種格式最大的差別了嗎？就是「自我描述的能力」。
看到purchaseOrder，可以知道這是「訂單」資料；看到shipTo就知道是「送貨資料」;看到billTo就知道是「收款資料」；而看到 Items 裡重覆多次的item，也能了解到是「訂單明細」。這不僅可以省去雙方大量的溝通時間，也可以減少系統建置時抓錯欄位的情形。

介紹了幾種資料格式之後，下一篇開始介紹應用案例。

本系列文章列表
Next : [XML]05-使用網站案例(RSS)